This invention relates in general to the field of computer architecture, and more specifically to a bus interface for communicating between computing devices.
A system bus in a computing system provides a communication channel between computing devices, such as microprocessors, and other devices such a memory, keyboard, monitor, video controllers, and sound generation devices, etc. The system bus typically includes data paths for memory addresses, data, and control information. In some instances, a microprocessor multiplexes (i.e., shares) address and data information over the same signal lines, albeit at different times. That is, a microprocessor sends address information out over the address/data pins during a first time period and later uses the same address/data pins to send or receive data. Alternatively, many microprocessors utilize separate signal lines for address and data information.
To better understand what a system bus is as well as the importance of bus interface standards, a general overview of the operation of a typical system bus is provided. Following that, a brief summary of modern system buses is given. Finally, an introduction to some of the needs that are not yet addressed by modern system buses is presented.
In operation, a microprocessor communicates with memory when it needs to fetch an instruction. During execution of that instruction, the microprocessor might be required to read data from memory, or from another external device such as an input/output (I/O) port. And, upon completion of the instruction, the microprocessor might be required to write data to memory, or to another external device. A typical scenario for accessing the memory to obtain the instruction and the data would be similar to the following:
1. The microprocessor presents a memory address for an instruction on the address lines of the system bus, and provides control information on the control lines of the system bus to indicate that the operation is a read.
2. In response to the address and control information being placed on the system bus, the memory places the instruction on the data lines of the system bus, which are then read by the microprocessor. The data is typically placed on the data lines N cycles after the address information has been placed on the address lines, where N is a positive integer and varies depending on the speed of the memory.
3. During execution of the instruction, if data is required, a memory address for the data is placed on the address lines of the system bus, and control information is placed on the control lines of the system bus to indicate a read.
4. Again, the memory places data corresponding to the memory address on the data lines of the system bus.
5. If the instruction needs to write to memory, the memory address for the write is placed on the address lines of the system bus, and control information is placed on the control lines to indicate a write.
6. N cycles after the memory address is presented, the data to be written is placed by the microprocessor on the data lines of the system bus. The memory uses the memory address presented in step 5, and places the data on the data lines into memory at that address.
One skilled in the art will appreciate from the above that the system bus provides the necessary physical interface between a computing device, and other devices that are external to it. The physical interface for a given system bus is typically defined in terms of the number of signal lines allocated to address, data, and control information, as well as the electrical characteristics of each of the signal lines. That is, typical system buses may provide anywhere from 20 address lines (for accessing up to 1 million different memory addresses), up to 45 address lines (for accessing up to 3.5 trillion different memory addresses). In addition, the size of the data portion of the system bus may vary from 8-bits in width, up to 128 bits in width. One skilled in the art will also appreciate that the wider the data width, the more information can be transferred at the same time.
From an electrical standpoint, system buses typically operate in the range of 0 volts to 5 volts, although other ranges are possible. Furthermore, particular bus interfaces define for each signal line on the bus, what logical state is meant for a particular voltage level. That is, the bus interface defines whether a logical 1 is provided by a voltage level of 5 volts, 0 volts (active low), or something else.
A system bus interface also provides the protocol necessary for communicating between devices. That is, the protocol defines when address, data, and control signals must appear on the system bus, in relation to each other. For example, in the illustration presented above, address information appears in parallel with control information. At some time later, data information is presented by the microprocessor, or is provided by memory.
A system bus protocol may also define how long signals must appear on the system bus. For example, a system bus protocol might require that address information appear on the bus for at least 2 clock cycles. And, the protocol might require that data must appear on the bus later than 2 cycles after the address information is removed. One skilled in the art will appreciate that such protocol definitions are specific to particular types of system uses.
With the above general background on system buses, a brief overview will now be provided for modern system bus interfaces.
The most common system bus interface in the world today is the Industry Standard Architecture (ISA) bus. In 1984, with the introduction of the Intel 80286 microprocessor, a new bus was required that could utilize the full 16-bit data bus of that processor. IBM decided to develop a new bus interface that could accept the data width of the 80286, and allow them to add more address and control signals to the previously designed PC bus. However, to allow the bus to remain backward compatible with devices designed for the PC bus, comprises were made. The resultant ISA bus was therefore something of a hybrid, offering advantages of increased speed (8 megahertz), increased data lines (16-bit), and increased address lines (24-bit), as well as additional interrupt and control lines, while at the same time separating the additional lines on a supplementary connector. This allowed legacy expansion cards with 8-bit data interface to be used, while adding additional data and address pins on the supplementary connector. The result was an 8-MHz bus clock, with a 16-bit data path, and 24 address lines to address 16 megabytes of memory. However, the number of I/O ports was still limited to 1,024 due to compatibility concerns with PC bus expansion boards.
As processor speeds increased, Intel separated the processor from the ISA bus to allow faster communication between the processor and memory, while still providing communication with slower ISA devices. The processor bus that is presently offered is referred to as either the host bus, or the Pentium bus. A typical implementation of the Pentium bus provides address, data and control signals between a processor and a memory controller, and operates at approximately 100 MHz. Also attached to this host bus is a chip, or chip-set that provides an interface between the host bus, and slower buses such as PCI and ISA. For a more thorough discussion of various PC bus architectures, the reader is directed to http://www.pcguide.com/ref/mbsys/buses/index.htm.
In each of the above-mentioned buses, the protocol associated with performing a read or write is essentially the same. That is, a processor first places address and control information on the host bus. At some later time, data is presented on the data lines of the bus, either by the processor (if the transaction is a write), or by memory (if the transaction is a read). In environments where there is only 1 device capable of initiating bus activity (a uni-master environment), such a protocol is generally sufficient. However, in environments where multiple processors compete for access to shared devices, arbitration is needed to assign time on the bus to the multiple processors.
For example, if there are two processors on a host bus, both competing for access to memory, typical systems provide an arbitration protocol between the devices to establish which one has the right to begin. On the Pentium bus, a processor requests access to the bus by asserting a xe2x80x9cbus requestxe2x80x9d signal. If the processor receives a xe2x80x9cgrantxe2x80x9d signal, then it begins a transaction by placing address and control information on the bus. When it receives (or writes) data on the bus, it relinquishes control of the bus to the next processor. If another processor required access to the bus during the transaction, it would have to wait until the entire transaction (including the address and data portions of the transaction) completed. In many situations, it is undesirable to deny a processor access to a bus pending completion of an entire transaction by another processor.
One solution to this problem has been to separate the address and data bus portions of the system bus, and to provide separate arbitration for gaining access to each of the buses. For example, rather than requesting access (or master) of the system bus, a first processor may request access to the address bus. If the address bus is available, the first processor can present address information on the address lines, even though a second processor is bus master of the data bus. Access to the data bus by the first processor operates in a similar fashion.
Thus, by separating arbitration for accessing the address bus from that of the data bus, multiple masters are allowed to utilize portions of the system bus simultaneously. An example of an environment that provides for such split address and data buses is the system bus for the PowerPC 603, manufactured by Motorola.
One skilled in the art should appreciate that when the address and data portions of a bus are separate, and are shared by multiple bus masters, a system must be developed for associating a data transaction with an address transaction. That is, if the address and data buses are truly separate, data may appear on the data bus many clock cycles after the address information was presented. In fact, in buses having split transactions, it is possible for two or more masters to present address information on the address bus long before data appears in response to the first address. In such an environment, it is essential to associate data on the data bus with either its associated address, or with a particular transaction.
In one environment, a transaction ID has been developed to tag all requests with a particular ID. When any data is presented on the data bus, the ID associated with the transaction is also placed on the data bus. This allows any processor on the bus to know whether the data being presented is associated with one of its outstanding transactions, and if so, which one. An example of using transaction ID""s to track multiple transactions in a split address/data bus environment is the R10000 manufactured by MIPS Technologies.
The above provides a general understanding of the progression of system buses, from multiplexed address/data lines in a single master environment, to split transactions in a multi-master environment. However, what has not been presented, and is heretofore unknown, is a bus interface that allows multiple transactions from multiple bus masters to be pipelined over separate address and data buses.
Therefore, what is needed is a system bus interface that prescribes a uniform protocol for allowing computing systems to be designed, whether they be single master or multi-master, that takes advantage of pipelined split transactions on separate address and data buses.
Moreover, what is needed is a system bus interface that allows master devices to communicate with external devices that have different interfacing capabilities. For example, older external devices may have a data bus width of just 16-bits. Newer devices may have a data bus width of 64-bits. Furthermore, each device may be capable of sending or receiving data in burst mode (described further below in the Detailed Description), but may have different buffer capacities. Therefore what is needed is a system bus interface that allows each master to configure transactions for each type of external device, within a split transaction environment.
In addition, what is needed, is a system bus interface that provides for coherent data tracking within a multi-master environment, when split transactions are performed across separate address and data buses.
And, what is needed is a system bus interface that reduces latencies typically associated with changing bus masters, on either or both of the address or data buses.
The present invention provides an innovative computer bus and bus interface that separates the address and data portions of transactions on a split transaction bus. By separating the address and data portions of a transaction, and presenting them on separate buses, multiple transactions, by either a single master, or multiple masters, can exist concurrently, without requiring that a first transaction be completed before beginning a second transaction. Such separation of transactions on a split transaction bus also allows for out-of-order completion of transactions.
In an embodiment of the present invention, a bus interface for a computing environment includes split transaction tracking and control, and flow control logic. The split transaction tracking and control establishes transaction ID""s for transactions to be presented on a computing bus that has separate address and data buses where the transactions have split address and data portions. The transaction ID""s have device ID""s and transaction tags for uniquely identifying all pending transactions on the computing bus. The transaction ID""s are presented on the computing bus commensurate with presentation of an address. Devices responding with data provide the associated transaction ID along with the data. The flow control logic determines whether devices that are being read from, or written to, by transactions, have adequate resources (buffers) to respond to the transactions. If the flow control logic determines that adequate resources are available, the transactions are presented to the computing bus. If the flow control logic determines that adequate resources are not available, the transactions are held until the resources become available. By providing such flow control, there is no need to retry any transactions resulting from inadequate resources.
One aspect of the present invention incorporates snoop control logic, and/or snoop management into devices on the computing bus. The snoop control logic, along with snoop management, insures that data coherency is maintained across multiple devices having instances of data, within the out-of-order, split transaction environment.
Another aspect of the present invention incorporates a data release mechanism. The data release mechanism is present within every master on the computing bus. It drives a data release signal during the last cycle of a data portion of a transaction to alert the next bus master that it can begin driving data. Tracking of data portions of transactions by the data release mechanism, and driving of the data release during the last cycle of a data transaction reduces the latency associated with sequential data operations.
In another aspect, the present invention provides a computer program product including a computer useable medium. Within the medium are a first computer readable program code and a second computer readable program code. The first code provides split transaction tracking and control to establish transaction ID""s for transactions to be presented on a computing bus having address and data buses. The second code provides flow control logic to determine whether devices being read from, or written to, by the transactions, have buffers currently available to respond to the transactions.